This invention relates to a method and apparatus for performing efficient interprocess communication in a multiprocess system. More specifically, this invention uses a transfer region located at a unique physical address to transfer information between the processes.
Computer operating systems place processes in different address spaces [1]. This is done primarily to be able to limit the ability of a process to inadvertently or maliciously cause damage to other running processes. By default, any writing or reading that occurs within a process occurs only on memory that it has access to, thus preventing it from affecting other processes. However, many times when executing programs, it is important to be able to perform inter-process communication or IPC. At a minimum, the process will need to communicate with the kernel, making requests for resources or services. Frequently, a process also needs to communicate with other processes, e.g., to coordinate together on a given task or to request information from a database server. To communicate within an address space is cheap, but to communicate across address spaces can be expensive since it often involves dispatch overhead, switching between address spaces, and transferring arguments between the address spaces.
In the past, all services of an operating system were contained in one address space, and while this allowed efficient communication, it had a series of unattractive properties. Many operating systems have moved functionality out of the kernel [2][3][4][5] and into user space. This technique is typically called the microkernel approach because it leaves a minimum amount of functionality in the operating system. A single-address-space operating system is more difficult to maintain and more difficult to debug since an error in one portion of a system could affect other unrelated portions. In contrast, a microkernel approach allows operating systems to be maintained easier since any service can (theoretically) be replaced without affecting other aspects of the operating system. It allows easier debugging because errors are contained within the module or service where they originate. However, implicit in this design, is that the various operating system modules implementing the different services reside in separate address spaces, thus increasing the expense of communicating within the operating system. The ability to perform efficient IPC in a microkernel becomes paramount to achieving a successful operating system. Indeed, systems in the past have failed because among other things they moved towards a microkernel architecture without an efficient IPC mechanism.
There are several different techniques that have been used in the past to communicate between processes in different address spaces. A standard technique is for the kernel to copy the arguments of the IPC out of the caller""s address space and into the callee""s address space [1]. Since processes trust the kernel, and the kernel is considered to be correct, this allows the two processes to safely communicate. Another known technique is for the kernel to map a portion of the caller""s address space into the callee""s address space. The caller can then place the data into that portion of its address space and the caller can read the data out from there. These and other techniques will perform well on some architectures while poorly on others. Our technique does not require kernel intervention to transfer the arguments and performs well across a wide set of architectures.
Research made significant performance improvements on inter-process communication between the mid-1980s and the mid-1990s. An early technique used to speed up IPC was to avoid requiring extra kernel copying of arguments. This idea led to the technique of using registers [6] to transfer information between the communicating processes. Other work [7] restricted IPC to use a remote procedure call (RPC) model. Further optimizations to the RPC path produced a package called LRPC [8]. This LRPC model was restrictive, and later work [9] relaxed the threading model to allow it to be used in a broader context. Other researchers [10] focused on coordinating the kernel and communicating threads to improve performance. Still other researchers looked at generalizing the interface [11][12] to present a better and more consistent communication to the user while still obtaining good performance. These techniques focused on achieving good uniprocessor performance. These techniques were modified to achieve good performance on multiprocessors [13]. Much of the work described above was targeted towards communicating only as much information as would fit in registers. Or, if the techniques allowed for more information to be transferred, the amount of space required made the approach untenable for a large multiprocessor system with many processors. The mechanism we describe in the next section, not only allows us to transfer moderate amounts of data (more than fits in registers), it also does not use an excessive amount of space. There is a need for a high performance, multiprocessor friendly mechanism which allows for the transfer of moderate amounts of data (more than fits in registers, but less than several megabytes) without using excessive memory space.
It is an objective of this invention to provide a mechanism for efficiently communicating moderate amounts of data between any two processes residing in separate address spaces.
It is a more specific objective of this invention to reduce kernel access to user space by avoiding mapping overhead during inter-process communication.
It is also an object of this invention to minimize cache and Translation Lookaside Buffer (TLB) misses.
On multiprogrammed systems the ability for processes (entities that exist in separate address space) to communicate is a fundamental service. The importance of this service dramatically increases in modern operating systems that are designed as microkernels whose services, such as file systems or security, are implemented in their own address space. This invention comprises of a mechanism for performing efficient Inter-Process Communication (IPC).
This invention provides for an inter-process communication transfer region having a unique physical address, where the region is shared among all processes on a given processor of a computer system. This unique physical address is then mapped into a virtual address in the address space of each of the processes. When a first of the processes needs to transfer data to a second of the processes, the first process stores arguments describing the data in the region. When a second of the processes needs to receive the data, the second process reads the data from the region by using a second virtual address in its address space which maps into the unique physical address.
It is preferred to use the same virtual address in each of the processes of the system, where the virtual address maps into the unique physical address of the IPC transfer region.
With this invention when control is passed from one process to another process, the IPC transfer region is automatically transferred between processes without any kernel overhead associated with the transfer of control of the region. The IPC Transfer Region is able to be accessed without locking. It is important to efficiently implement IPC transfers in modern operating systems that are designed as microkernels, whose services, such as file systems or security, are implemented in their own address space. The need for locking is obviated by detecting an xe2x80x9cin usexe2x80x9d IPC Transfer Region at preemption time and saving its state. The IPC Transfer Region effectively extends the register set of a machine by allowing larger amounts (more than fits in registers) of data to be efficiently transferred across address space boundaries. This technique is suitable for transferring moderate amounts of data, where moderate is defined as more than would fit into the registers, but less than several megabytes. Services provided by modern operating systems can take advantage of the IPC Transfer Region to efficiently communicate with other services, the user, and the kernel.